HW#3 --- last modified February 17 2019 19:28:44..

Solution set.

Due date: Nov 1

Files to be submitted:
  Hw3.zip

Purpose: To experiement using a version control program for managing your projects. To write web programs which make use of a database. To learn how to validate simple forms using Javascript.

Related Course Outcomes:

LO3 -- Write server-side scripts that process HTML forms.

LO4 -- Write client-side scripts that validate HTML forms.

LO5 -- Develop and deploy web applications that involve components, web services, and databases.

Specification:

For this program, you are going to create a url shortening service similar to: http://tinyurl.com/, http://bit.ly/, or http://j.mp/. Often such services are used to post links into Twitter feeds, so the shorter the url (so more of the 140 char limit to use for something else), the better. For this assignment, let's assume your web app lives in the document root directory. When a user comes to the page:

http://localhost/

The user should see a page explaining what your site is, and having a form that allows the user to shorten a url. (Don't hard-code localhost anywhere. The grader had significant problems getting people's code to work on HW2 because of hard-coded paths, etc. This meant the grader had to go around editing code in places other than the config directory to get stuff to work. If your Hw3 suffers from this, your homework will not be graded and will receive a score of 0. So please make your code as relocatable as possible.) The form should have a field asking for a url to be shortened, and also give a place to put a vanity name for the short url.

To shorten a url your app will use the PHP sha1 function to create a hash of the url to shorten. It will then take some number of char's out of this hash from the beginning and base64 encode those (using the built-in PHP base64 functions). The exact number of chars should be at least six as we want to be relatively immune to birthday attacks. In cases where the vanity url field was not left blank, then no hashing is done and instead the vanity string is associated with the url to be shortened. The (url, hash/ vanity string) pair should be stored in a database table with the hash/vanity string as the key. If a hash/vanity string is already in use, some kind of error message should be displayed, but the old (url, key) pair should be left unchanged. When a user makes a request of your site using:

http://localhost/?c=lookup&k=some_key

your web app should output an HTTP Location header to redirect the user to the url corresponding to that key. As you can see based on the format of this url, I expect the code for your homework to be organized into the same folder set-up as HW2. For this homework, you are required to use, object-oriented PHP. i.e., uses classes, for your models, views, and controllers. Location lookups should be flexible, so if a user makes a request:

http://localhost/?c=lookup&k=some_key/some_relative_path

the user should be redirected to:

the_looked_up_url/some_relative_path

In addition to the basic url shortening service described above, your web app should have a sign-in page, and allow for people to create new accounts. When someone creates a new account your app should verify using Javascript that all the form fields needed to create a new account have been filled-in. If a user is logged-in, and they use the url shortening service, then the (url, key) pair is associated with their account. For a logged-in user, on the main page, they should see a link "My Statistics", if they go to the page this points to they should see for each shortened url they've created, statistics about how often it has been clicked, as well as a break down of the number of clicks by different HTTP REFERER.

The final aspect of this assignment is to use git version control while creating your app. Your Hw3.zip file that you submit should be a zip file of your git repository. Break the assignment into at least six issues/bugs. In the config folder, have a file issues.txt where you list these issues and for each issue, list the team member responsible for that issue. Your git repository should have regular commits into it that correspond to these issues and maybe sub-issues. No more than hundred lines should change between commits. Commits should be time-wise far enough apart that a human could actually have typed the information that is being committed.

Point Breakdown